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ABSTRACT 

A habitat, on either the surface of the Moon or 
Mars, will be designed and built with the 
proven technologies of that day. These 
technologies will be mature and readily 
available to the habitat designer. We believe 
an acceleration of the normal pace of 
automation would allow a habitat to be safer 
and more easily maintained than would be the 
case otherwise. This document examines the 
operation of a habitat and describes elements 
of that operation which may benefit from an 
increased use of automation. Research topics 
within the automation realm are then defined 
and discussed with respect to the role they can 
have in the design of the habitat. Problems 
associated with the integration of advanced 
technologies into real-world projects at NASA 
are also addressed. 


INTRODUCTION 

A habitat, on either the surface of the Moon or 
Mars, will be designed and built with the 
proven technologies of that day. These 
technologies will be mature and readily 
available to the habitat designer. We believe 
an acceleration of the normal pace of 
automation would allow a habitat to be safer 
and more easily maintained than would be the 
case otherwise. Because only mature 
technologies will be useful to habitat 
designers, it is necessary to assess the current 
maturity of automation. "Automation", as 
used in this document, refers primarily to the 
advanced software control of a complex array 
of equipment and sensors, and secondarily to 
the isolated operation of an autonomous robot. 
A "habitat" is defined to be the shirt-sleeved 
living and working quarters of a crew in a 
hostile space-based environment. The specific 
habitat under consideration is that defined as 
Option 5A in the Habitation and Human 
Systems Addendum [1] to the Report of the 90- 


Day Study on Human Exploration of the Moon 
and Mars [2]. This paper examines the 
operation of a habitat and describes elements 
of that operation which may benefit from an 
increased use of automation. These elements 
include fault-tolerance, graceful degradation, 
localization of failures, human-machine 
interaction, non-invasive repair strategies, 
and some logistics matters. Some research 
topics within the automation realm are then 
defined and discussed with respect to the role 
they can have in the design of the habitat. 
These topics include fault-diagnosis and 
recovery methods, planning, and speech- 
recognition. The research topics are discussed 
only with reference to their potential 
application to the habitat design. More 
detailed sources of information on specific 
topics are at times suggested. 


LOGISTICS 

Logistics involves the design, operational 
planning, and provisioning for the habitat. 
Logistics has historically taken a back seat to 
most other disciplines during development 
projects. In the creation of a remote space- 
based habitat, however, we can ill afford to 
have it remain there. Many details need to be 
decided upon in creating a viable logistics 
support plan for a space habitat. One of the 
largest decisions involves the placement of 
the depot facility. Having a depot facility co- 
located with the habitat may prove to be a 
necessity due to the great number of line 
replaceable units (LRUs) that would 
otherwise have to be present at the site. Co- 
locating a depot-level repair facility with 
the. habitat, however, will be a unique 
undertaking. In the US armed forces, for the 
support of millions of pieces of electronic 
equipment, there exist a handful of depot 
level repair facilities. The habitat depot 
will, however, fulfill a much more exclusive 
support role than a general purpose depot. 
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Regardless of depot placement, the difficulty 
in maintaining logistics support for the 
habitat will be great. Logistics support for 
Operation Desert Storm has been a topic of 
conversation in recent months. The inability to 
get the proper supplies to our armed forces in 
the Persian Gulf could have resulted in 
unnecessary loss of life. Our inability to get 
the proper supplies to a space habitat could do 
likewise. Whatever logistics plan we decide 
on will have to accommodate complex, risky, 
and inherently unreliable resupply missions. 

It is important to design the subsystems of the 
habitat to capitalize on commonality. Having 
different subsystems with interchangeable 
LRUs, if possible, would add depth and 
flexibility to system maintenance. An 
overriding concern of this design process will 
be to keep unique parts counts at a minimum. 
This will reduce the cost of initially 
outfitting the habitat’s repair facilities and 
reduce the ongoing life cycle costs associated 
with resupply. Perhaps a logistics "Tiger 
Team" could be assembled whose purpose 
would be to minimize the number of unique 
components incorporated into the subsystem 
designs, as well as to minimize the support 
items required to maintain the subsystems. 
Without such an influence it is far too easy for 
subsystem designers to use either what is 
available to them or what they are most 
comfortable with. 


DESIGN 

Each of the subsystems of the habitat will be 
integral in sustaining life. This will require 
constant availability of each of the 
subsystems. The ultimate design goal of a 
continuously operating system is for no one 
failure to incapacitate or degrade system 
performance. An equally laudable repair goal 
is for no one repair to require a suspension of, or 
degradation of, system performance. Fault 
tolerant system operation, graceful system 
degradation, and non-invasive repair 
strategies will be necessary elements of the 
design of the habitat. 

Constant availability implies the presence of 
fault redundant operation (to ensure stable 
operation of habitat functions); localization of 
failures (to prevent cascading effect of 


failures); subsystem isolation (to prevent 
cascading effect of failures between 
subsystems); and an adequate logistics 
pipeline (to allow for repair of faulty 
equipment in a timely manner). In a terrestrial 
factory this presents a difficult, but doable 
task. On the Moon or Mars it will be much 
more difficult, with the consequences of 
failure being much more grave. 

Fault Redundancy 

Fault redundancy usually takes the form of 
hot and cold spares and, in some cases, entire 
backup subsystems. Perhaps some redundancy 
of this form may be necessary, but an 
extremely high cost would be paid for it. The 
cost for launching a metric ton of cargo into 
orbit is extremely high; and this apart from 
placement of the cargo on the surface of the 
Moon or Mars. Because of the conflict between 
the need for redundancy and its high cost, an 
analysis is needed to determine the most cost- 
effecdve forms of redundancy to employ in the 
design of the habitat. 

Subsystem Commonality 

The subsystems, while varying greatly in 
their duties and designs, provide an 
opportunity for exploitation of their common 
features. Each subsystem will be required to 1) 
plan and control it's own operations; 2) 
determine it’s own ability or inability to 
function; 3) cooperate with other subsystems as 
necessary; and 4) communicate with a system 
level executive as necessary. These points can 
be restated as 1) planning and scheduling; 2) 
fault detection, isolation and recovery (FDIR); 
3) interfacing; and 4) hierarchical 
communication and control. Planners and 
schedulers, unique to each subsystem, should 
be able to communicate with one another with 
ease in that they will be required to operate 
on similar types of objects. Fault diagnostic 
programs should operate on similar principles 
so as to benefit one another during their 
operation. The philosophy behind subsystem 
interfaces should be defined early and 
adhered to strictly during the design of the 
habitat. Subsystem interfaces should be 
thought of as part of the system and designed 
in as opposed to being patched in when found 
necessary. Design documents should be created 
which encourage and enforce design 
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commonality and consistency in subsystem 
interfacing. These principles, applied 
correctly, should result in cooperation of the 
subsystems at the system level. 

Physical Dispersion of Subsystems 

While we want the subsystems to use common 
parts and to be built with similar design 
paradigms, they will also have to remain 
electronically isolated from one another to 
prevent the possibility of failures leaping 
across subsystems. To minimize the potential 
hazardous effects physical phenomena, such 
as fire or flooding, may have on the 
equipment, the subsystems themselves should 
also be distributed over a large physical area. 

Importance of System "State" Maintenance 

Repair strategies must be developed that take 
into account the state of the equipment and 
potential loss of state information via 
failures. "State" refers to the sum of the many 
facts which together define a point in time in 
the life of the habitat. It is important that 
this abstract state represent the true state of 
the habitat environment as best it can. A 
sophisticated network of sensors of all types 
will help us to maintain this state validity. 
This abstract state will then be used by the 
various health monitoring systems and fault 
detection programs to assist in the 
determination of proper equipment and 
subsystem operation. It provides a model of 
the habitat with which the various 
subsystems can reason. Reasoning upon this 
abstract state is known as Model-Based 
Reasoning (MBR). 

Each of the subsystems will have different 
levels of automated response, implemented at 
the hardware level, to ensure the security of 
both equipment and personnel. In design 
terminology, this lowest level of automated 
response to the detection of hardware faults, 
is known as safing the system. The impact of 
safing will first be felt, via the sensors, by a 
system executive. (We use the term Habitat or 
Space Habitat Executive (HE/SHE). HE will 
be used for consistency). The system state will 
then be assessed and recovery procedures, 
appropriate to the situation, implemented. 
Perhaps HE could be sent a "heads-up" 
message just prior to a subsystem safing itself. 


In this way the strategy used in resuming 
operation could have been designed 
beforehand and thus resumption of processing 
could proceed in a more studied fashion. 

This implies a tight coupling of the hardware 
and software. This tight coupling can only 
exist if it has been designed into the system. 
To accommodate this we should ensure a tight 
communication exists between the hardware 
and software developers during the design 
stages. A lack of communication would lead to 
complication of the software designs and a 
reduction in the efficacy of the software in 
handling unusual states. 

Human-Machine Interaction 

Input/Output (I/O) in the habitat will take 
many and varied forms. Traditional computer 
input via the keyboard and output via the 
computer screen will be assisted by speech 
recognition systems and natural language 
understanding capabilities; visual control, 
possibly with the aid of head gear such as is 
used in virtual reality testbeds; hearing, via 
our ability to distinguish variations in tones, 
as well as the location in three-dimensional 
space of the source of said tones. 

It should prove beneficial that the computer 
react to the voice of the habitat occupants. 
Voice input will allow a tangential task to be 
started while not disrupting the primary task 
to which the speaker is employed. A driving 
principle behind the development of the 
habitat's voice and data control systems, 
should be the desire to not enslave the habitat 
occupants to use of a stringent syntax. Stringent 
enforcement should be needed only when 
commands are ambiguous or nonsensical. 

Visual "heads up” displays, such as are now 
used in jet cockpits, and flat wall displays and 
touch screens can be used to free the habitat 
occupants from the need to sit in front of small 
computer screens. Virtual reality helmets can 
be used daily to simplify the control of robots 
outside of the habitat. 

We have only begun to explore the concept of 
using hearing in human machine interaction. 
The auditory sense can provide an alternate 
route for critical information in complex 
environments during periods in which the 
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user's visual capacity is already greatly 
taxed. "Ames is currently investigating the 
underlying perceptual principles of auditory displays 
and is also developing a prototype signal processor 
based on these principles. Rather than use a spherical 
array of speakers, the prototype maximizes portability 
by synthetically generating 3-D sound cues in real-time 
for delivery through earphones. Unlike conventional 
stereo, sources will be perceived outside the head at 
discrete distances and directions from the listener. This 
is made possible by numerically modelling the effects 
of the outer ears on the sounds perceived at various 
spatial locations." [3] These discoveries, and the 
discoveries of other related programs, are 
rapidly expanding the role of hearing in the 
design of future man-machine systems. 

The occupants of the habitat should be 
considered the equivalent of jet aircraft pilots 
for the purposes of habitat design. This is 
because, like jet aircraft pilots, they will be 
hard-pressed during critical events to absorb 
all of the information available to them. This 
is especially true if we do not attempt to better 
distribute the sensory load over all of the 
senses. Because of this similarity we should 
assess the state of aircraft cockpit design. 
Advances in the area of jet aircraft human- 
machine interaction should be given serious 
consideration in the design of the habitat. 
Ames Research Center is now preparing a 
document which addresses the rationale and 
philosophy of human-centered aircraft 
automation. It will address the issues posed by 
aircraft automation as it has evolved over the 
past sixty years [4]. 

Having multiple forms of I/O also provides an 
inherent redundancy and flexibility in day to 
day operational use and control of the 
habitat. When one form of control is 
incapacitated, for whatever reason, the 
chances would be much greater that another 
I/O route exists to fulfill a requirement. 


OPERATION 

The subsystems of the habitat will interact 
constantly. In large systems, subsystem 
interaction is often handled on an individual 
basis, with interfaces between subsystems 
being defined as needed. Within the habitat 
we will need to constrain subsystem 
interactions to isolate them from one another. 
This isolation will allow for 1) the 


independent development of FDIR programs 
for each subsystem; 2) the development of a 
system-wide health monitoring and fault 
diagnostic program; and 3) the isolation of 
failure effects to the subsystem in which the 
failure occurs. 

An example of the need to coordinate the 
activity of subsystems is exemplified by the 
direct correlation between the consumption of 
power and the generation of heat. The load 
placed on a thermal cooling system is driven 
by the generation of heat which is a side- 
effect of power usage. As power usage increases 
the need for thermal cooling increases. When, 
however, thermal cooling capacity is 
diminished in some way it may be necessary to 
reduce the generation of heat, which can only 
be done by eliminating non-essential power 
usage. It is the automation of such subsystem 
interactions that would help simplify the 
lives of the habitat occupants. 

Sensors will maintain a constant flow of real- 
time information to the individual subsystems 
of the habitat as well as to HE. HE will 
resolve the conflicts between subsystems’ 
individual plans and schedules in accordance 
with a greater awareness of the proper 
subsystem roles in the habitat. This 
arbitration between subsystems is not intended 
to layer a bureaucracy on the running of the 
habitat. Having HE arbiter ail subsystem 
interaction would produce an unacceptable 
bottleneck in operation and would increase the 
damage potential of single point failures. It's 
role here would be strictly that of resolving 
subsystem conflicts. 

Another aspect of the role of HE involves the 
scheduled interaction of humans with 
equipment. Almost all human activity 
impacts equipment resources in some way. HE 
will be responsible for the control and sharing 
of these system resources. 


MAINTENANCE 

With manpower being the most precious 
resource of the habitat, both morally and 
financially (some figures place the hourly cost 
of having astronauts in orbit at $35,000 [5]), we 
must design the subsystems of the habitat to 
function as autonomously as is practicable. 


394 



The normal operation, detection and diagnosis 
of faults, and repair of subsystems, should be 
automated to the greatest extent possible. 
Subsystem health monitoring should allow for 
automated recognition of, and rerouting of 
subsystem operation around, minor faults 
without impacting system operation. Health 
monitoring should also provide automated 
diagnosis of minor faults which do impact 
subsystem operation as quickly as possible. 
Defective LRUs will be replaced by human 
repairmen and either disposed of or forwarded 
to the depot for repair. Over time, perhaps 
automated subsystem assistants can help with 
LRU replacement and disposition. 

Robotic Depot Repair Facility 

An automated depot-level repair facility is 
being considered for the habitat. This could be 
realized by developing a highly automated 
facility for the repair of all repairable LRUs. 
Automated component-level equipment repair 
can be facilitated by such things as 1) human 
staging and previewing of LRUs; 2) Optical 
Character Recognition (OCR) coding of all 
LRUs and replacement part storage locations; 
3) recording of all LRU component placements; 
and 4) a highly constrained environment 
within which the robot can perform the 
repairs. This repair strategy will require 
extensive development and may need to be 
phased in at an operational habitat. 

Active and Passive Maintenance 

System maintenance will have a passive and 
an active element. The passive element can be 
thought of as a health monitoring system. The 
role of this system is to minimize the number 
of malfunctions requiring immediate operator 
attention. The system should be capable of 
handling the great majority of malfunctions, 
thus allowing the habitat occupants to 
perform other, more critical tasks. It 
incorporates 1) trend analysis which can lead 
to preventive maintenance tasks being 
assigned to prevent future failures; 2) 
automatic reconfiguration of system elements 
to bypass suspected failed LRUs; 3) control of 
fusion of sensors and static data displays to 
keep the habitat occupants informed of system 
status; and 4) interactive data displays to 
inform the more inquisitive user of the state of 
the habitat. 


Active maintenance will be in the form of 
FDIR programs, unique to each subsystem, 
capable of fault-isolation to the LRU level. 
The FDIR programs will be developed 
independent of one another but with a common 
design methodology to allow for 
communication in the larger system-wide 
FDIR program. The subsystem FDIR programs 
will communicate with one another via a 
blackboard data architecture, controlled by 
HE, allowing them to share information vital 
to one another. Using a knowledge-based 
systems approach, the same inference engine 
design for each of the subsystems can be used 
while allowing the data unique to each 
subsystem to determine the troubleshooting 
path. This will facilitate a more tractable 
validation and verification of the various 
FDIR programs and help simplify the 
development of a system-wide FDIR program. 

The transition from passive to active 
maintenance will at times take the form of 
responses to status updates (in the case of non- 
critical failures) or responses to alarms (in the 
case of critical failures). HE will be fed 
information from each of the subsystems at 
specified time intervals, as well as 
asynchronously in the event of anomaly 
detection or user interaction. 


APPLICATION OF AUTOMATION 

Candidates for automation, of either form 
defined earlier, are those tasks which are 1) 
time consuming; 2) repetitive; 3) uninteresting; 
4) well-defined and highly constrainable; 
and/or 5) operate in isolation. This is not a 
definitive list in determining what to 
automate, but does serve as general guidance 
when considering candidates for automation. 

Automation candidates already mentioned 
include the health monitoring system, HE, the 
FDIR programs, planners and schedulers 
unique to each subsystem, and the robotic 
depot repair facility. Other tasks, which 
might lend themselves at least partially to 
automation, are "household chores", such as, 
food preparation and cleanup, vacuuming and 
dusting, storage and access of work area tools, 
inventory control and replenishment, waste 
disposal, and bathroom cleaning. 
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As the habitat is to be manned continuously, a 
means of locally producing fresh vegetable 
produce will be necessary. A "salad machine”, 
that will provide a variety of fresh 
vegetables for astronauts on long voyages, is 
now operational at NASA Ames. [6] The near- 
term goal is to provide astronauts of Space 
Station Freedom with fresh salads. The 
machine may also provide a beneficial side- 
effect in improving the morale of the crew by 
offering them a creative outlet during their 
free time, such as is provided by tending a 
garden on Earth. 

Many opportunities exist for the inclusion of 
automation in a space habitat. A "a day in the 
life of the habitat" scenario, developed early 
on in the project, would provide a model upon 
which automation concepts could be modeled 
and thus compared against their more 
traditional counterparts. The model would 
also provide an environment within which 
the interaction of tasks effected by automation 
could be assessed. 


RESEARCH 

The following research topics have been 
referenced previously in the text. Appearing 
here is a brief description of their current 
capabilities and their weaknesses with 
respect to our application of them in design of 
a habitat. 

Speech Recognition 

Speech recognition is the capacity for a 
computer to "hear" and correctly identify the 
Spoken word. "Few applications of speech- 
recognition technology have reached beyond simple, 
speaker -dependent, isolated-word recognizers with 
vocabularies of a dozen to a hundred words. Small 
vocabularies and poor accuracy have limited the 
applications suitable for speaker-independent 
systems." [7J Though this was stated over four 
years ago, and much progress has been made 
since that time, the more successful systems 
still recognize only isolated words or short 
phrases, and require "training" to recognize 
each speaker’s voice. There is also usually no 
"understanding" of the words spoken 
(although it can be argued that this is an 
extension to the concept of speech recognition). 
The words are usually used only as dumb 
commands, without semantic significance, in 


the execution of predefined actions. Further 
research needs to be performed to improve 
upon speech recognition in the areas of 
continuous-speech, speaker-independence, 
vocabulary size, and accuracy. SRI 
International has been working on a 
continuous-speech, speaker-independent, 
20,000 word speech recognition system for 
DARPA. [8] This system, when completed, 
should be evaluated with respect to its 
potential usefulness in the habitat. 

Natural Language 

Natural language can also be thought of as 
speech understanding. Speech recognition 
identifies the words, but natural language 
understanding attempts to derive meaning 
from the words. This meaning is needed, on the 
computer side, to "understand" what it is being 
commanded to do. In addition, the computer 
needs to be capable of generating semantically 
correct replies for the user. Natural language 
is now advertised to be resident in many newly 
released software products. The natural 
language referred to is usually nothing much 
more than lazy syntax enforcement in 
combination with COBOL-like command 
statements. While this is in itself a useful 
software concept, it is not what we have 
defined h ere as natural language 
understanding. To be useful in the operation of 
the habitat, much more research in natural 
language understanding needs to be done. At 
this stage we may be better served by 
integration of the current, more popular, 
meaning of natural language. 

Model-based Reasoning (MBR) 

"Model-based reasoning uses an internal symbolic 
model of the system of interest and updates the state of 
this model based on sensor evidence and cause/effect 
analysis.” [9] MBR has several advantages over 
other forms of fault diagnostic systems. It can 
handle systems too large for traditional 
troubleshooting procedures developed in 
conjunction with a Failure Modes and Effects 
Analysis (FMEA). It can also lead to the 
discovery of faults other than those for which 
it has been proven to work. The model -based 
capabilities of TEXSYS were shown to be 
advantageous, particularly for detection of unforeseen 
faults and sensor failures.” [101 It may also require 
less of a knowledge engineering effort, as the 
model is based more upon device behavior and 


396 



less upon heuristics unique to the domain. MBR 
has its drawbacks, however, one of which is 
excessive use of processor time, as shown in the 
following excerpt. "It was necessary to rely on a 
classification or rule-based approach to interpret 
conflicts in the expert system’s model, given the 
slowness of structural (model-based) reasoning. [10] 
Another weakness of the MBR approach is the 
time lag which exists in updating the model to 
reflect what has happened in reality. Often, 
during times of increased activity, valid 
states are interpreted as error states due to the 
model having been inconsistent, for perhaps 
only a moment, at the time that the data were 
sampled. Research in MBR needs to focus on 
how to better represent the actual state 
expected in the model and how to reason in 
more general, domain independent ways. 

Planning 

"Any intelligent system that operates in a moderately 
complex or unpredictable environment must be 
reactive, that is, it must respond dynamically to 
changes in its environment." [9] Planning is one 
activity which we hope to have migrate to 
the computer in great part due to its time- 
consuming nature. If done manually, in the 
habitat, little time would be left for other 
activities. The current state of planners, 
however, does not support the depth and 
flexibility required of the planners in the 
habitat. Planners are incapable of working on 
general problems and may continue to be for 
some time. Successful planners sometimes work 
only within oversimplified domains or are 
very domain specific. Planning in the midst of 
a dynamic domain also changes the content of 
the plan continually, often invalidating it 
before it is complete. Much more basic research 
in planning in a dynamic domain needs to be 
performed. Perhaps, for habitat needs, 
research should focus on human assisted 
planning in addition to the more popular 
autonomous planning. Some excellent 
suggestions on space-based planning have been 
made in Reference 5 (pages 4-8 thru 4-10). 


CONCLUSIONS 

The following quotations are all taken from a 
MITRE Report entitled. Space Station 
Freedom Program Advanced Automation: 
Volume l [11] and are referenced here without 
additional comment. 


"The research community can be characterized 
as Ptolemaic: advanced automation is the 
center of their universe, the rest of the 
universe orbits around this center." page 6 

"A Copemican view of advanced automation 
is required if these technologies are to be used 
within operational applications." page 7 

"...the technology used for Apollo and Shuttle 
was successful and should be good enough..." 
page 8 

’Too much innovation causes disruption, while 
excess stability creates stagnation. There is 
currently no environments for transitioning 
innovative technologies and applications into 
the stable production environments." page 11 

"... there is a distinct gap that must be filled 
between the relatively unconstrained 
environments of the test beds and the 
constrained production facilities and 
operations environments." page 14 

Suggestions for Future Consideration 

Throughout this paper questions have been 
raised and further studies have been 
suggested. To again highlight them they 
appear here in bullet form. 

• To assist in incorporating automation into 
the operation of the habitat, we must make 
the habitat designers aware of the areas 
which may benefit from automation. 

• An analysis is necessary to determine the 
most cost-effective form of redundancy to be 
employed in the design of the habitat. 

• Perhaps a logistics "Tiger Team" could be 
assembled for the purpose of maximizing 
commonality and minimizing the number of 
unique components incorporated into the 
subsystem designs. 

• The location of the depot repair facility 
will provide the foundation for making many 
future habitat design decisions. 

• Subsystem interfaces should be designed in 
and not developed ad hoc. 

• Planners, schedulers, and FDIR programs. 
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unique to each subsystem, should use common 
data structures to ease system communication. 

• Habitat hardware design should consider 
the effect safing will have on HE. 

• Having I/O take varied forms will provide 
an inherent redundancy in the day to day 
operational use and control of the habitat. 

» To assist in the assessment of automation 
scenarios perhaps a "day in the life of the 
habitat" model could be developed. 

• Perhaps NASA could address the lack of 
suitable environments for the transitioning of 
innovative technologies and applications into 
stable production environments. 
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